-
Notifications
You must be signed in to change notification settings - Fork 27.4k
test($compile): work around Chrome issue with reported size for <foreignObject>
#15458
test($compile): work around Chrome issue with reported size for <foreignObject>
#15458
Conversation
…eignObject>` Since Chrome 53-57+, the reported size of `<foreignObject>` elements and their descendants is affected by global display settings (e.g. font size) and browser settings (e.g. default zoom level). This could cause tests incorrectly failing due to such settings. In order to avoid false negatives, we now compare against the size of the equivalent, hand-written SVG instead of fixed widths/heights. Fixes angular#15333
|
||
expect(isHTMLElement(testElem)).toBe(true); | ||
expect(referenceBounds.width).toBeGreaterThan(0); | ||
expect(referenceBounds.height).toBeGreaterThan(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any reason to believe that this might not be greater than zero?
And even if it was zero, do we care? If that is what the browser does with the handwritten HTML then so be it?
Right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is just a sanity check that we are doing the right thing and the hand-written HTML produces something. If this changes in the future (e.g. the hand-written HTML does not produce the expected result) and we break $compile
, the tests might pass although the code will be broken.
It is a somewhat far fetched scenario, so I can remove it if you think it is more confusing than helpful.
A minor comment but LGTM, with or without changes. |
…eignObject>` Since Chrome 53-57+, the reported size of `<foreignObject>` elements and their descendants is affected by global display settings (e.g. font size) and browser settings (e.g. default zoom level). This could cause tests incorrectly failing due to such settings. In order to avoid false negatives, we now compare against the size of the equivalent, hand-written SVG instead of fixed widths/heights. Fixes angular#15333 Closes angular#15458
These tests also fail on Edge 14, but this patch fixes it (tested locally) |
Doesn't this need to be backported @gkalpak? |
…eignObject>` Since Chrome 53-57+, the reported size of `<foreignObject>` elements and their descendants is affected by global display settings (e.g. font size) and browser settings (e.g. default zoom level). This could cause tests incorrectly failing due to such settings. In order to avoid false negatives, we now compare against the size of the equivalent, hand-written SVG instead of fixed widths/heights. Fixes #15333 Closes #15458
Done! Thx :) |
…eignObject>` Since Chrome 53-57+, the reported size of `<foreignObject>` elements and their descendants is affected by global display settings (e.g. font size) and browser settings (e.g. default zoom level). This could cause tests incorrectly failing due to such settings. In order to avoid false negatives, we now compare against the size of the equivalent, hand-written SVG instead of fixed widths/heights. Fixes angular#15333 Closes angular#15458
What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Fixes two (potential) test failures on Chrome 53-57+.
What is the current behavior? (You can also link to an open issue here)
These tests can fail on Chrome, because the reported size of the inner divs is subject to global display settings (e.g. font size) and browser settings (e.g. default zoom level).
See also #15333.
What is the new behavior (if this is a feature change)?
The assertions are now more robust by comparing against the size of the equivalent, hand-written SVG instead of fixed widths/heights.
Does this PR introduce a breaking change?
No.
Please check if the PR fulfills these requirements
Docs have been added / updated (for bug fixes / features)Other information:
Fixes #15333